-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added agent option to http transport #439
Conversation
let's default this to the current version of the transport. ex
While not here, we've had quite a discussion elsewhere on it. openzipkin/zipkin-reporter-java#142 |
Based on node-fetches docs and the nodejs http.Agent docs which it refers, I believe the user-agent referred to in: openzipkin/zipkin-reporter-java#142 would simply be a matter of updating the header[user-agent] property, while the Agent option I've added would refer to an http.Agent. The http.agent would be responsible for managing connection persistence and reuse for HTTP clients, such as sockets, certs, etc. I believe The current default uses the http.globalAgent, which has the base defaults (this would reflect current behavior where no http.agent is being used) I've also updated the |
sorry wrong agent I guess! |
declare class HttpLogger implements Logger { | ||
constructor(options: { | ||
endpoint: string, | ||
httpInterval?: number, | ||
jsonEncoder?: JsonEncoder, | ||
httpTimeout?: number, | ||
headers?: { [name: string]: any }, | ||
agent?: Agent | (() => Agent), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is (() => Agent)
the same effect as null?
Let's add typescript and javascript tests for this parameter to make sure someone later doesn't accidentally break what you need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(() => Agent)
is the equivalent of a function which returns an Agent
This follows node-fetch which will accept an HTTP(S) Agent or a function which returns a HTTP(S) Agent
I have also added typescript tests, to ensure the current functionality & also the newly added agent types.
@@ -14,7 +14,7 @@ | |||
"lint:ts": "tslint -c tslint.json -e './packages/**/node_modules/**/*.ts' './packages/**/*.ts'", | |||
"lint": "npm-run-all --parallel lint:*", | |||
"test:es": "npm run lerna-test", | |||
"test:ts": "tsr packages/zipkin/test-types/*.test.ts --noAnnotate --libDeclarations && mocha --opts test/mocha-types.opts", | |||
"test:ts": "tsr packages/*/test-types/*.test.ts --noAnnotate --libDeclarations && mocha --opts test/mocha-types.opts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated this to process test-type/*.test.ts
tests in all packages. This reflects the second mocha command which uses test/mocha-types.opts
and attempts to run test-type tests in all packages.
Build failed on the Kafka Transport. The only change which could affect this (at least based on my current understanding of the project) is the change to the Is there possibly another issue going on? Or an intermittent issue unrelated to these changes? |
}); | ||
|
||
it('should accept Http(s) Agent or function which returns Agent', () => { | ||
const agents = [new HttpAgent(), new HttpsAgent(), () => new HttpAgent(), () => new HttpsAgent()]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so this test makes sure it doesn't crash in the constructor. am I understanding that right?
I wonder if it would crash later. It might be confusing to have a test without assertions I mean.. wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya it's testing the constructor. I've added an expect statement to confirm this.agent
is properly being set and defaulting to null
if it is not provided.
Beyond that, it is only being forwarded to the fetch call. Ideally I could confirm that fetch is being called with the agent, however due to the node-fetch
implementation and sinon
restrictions, it doesn't seem feasible to perform such a test without some hacky solutions.
kicked build in case it is a flake |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work
Sorry I am too late for this discussion.
Out of curiosity: is this agent is also the same agent supported in axios:
https://github.com/axios/axios/blob/master/README.md#request-config
In addition, I feel like we haven't added any sort of documentation about
this new feature. Could we add at least in tsdoc about this new parameter?
In any case great work @RAWeber!
|
@jcchavezs looks to be the same agent supported by Axios, as both just accept a Nodejs http(s) Agent. And I will look into adding some comments/documentation this week! |
Provide option to set a custom agent to use with node-fetch.
https://www.npmjs.com/package/node-fetch#custom-agent
This will allow users to specify any networking related options. For example, users can provide client certificates to hit mTLS endpoints, or CA certificates to use self-signed certificates.
Will use default agent if no agent option passed.